1. Field of the Invention
The invention relates generally to storage systems and more specifically relates to interrupt processing in a storage system environment.
2. Discussion of Related Art
Generally, a storage controller is used to manage the devices of a storage system (e.g., storage disks, interfaces, etc.). A storage controller may include, for example, a host bus adapter for coupling a host system to one or more storage devices. The storage controller may also include a controller device embedded within a storage system. A storage controller typically comprises a processor/CPU coupled with a plurality of storage devices (e.g., hard disks, flash memory, etc.) through appropriate interfaces. The processor performs read or write requests from a host system that are directed to the storage devices. In addition, further interfaces may be coupled with the processor of the storage controller for communication with host systems. Each of these interfaces may cause the storage controller to generate a signal indicating a need for intervention by the processor. The storage controller itself may also internally generate such signals (e.g., owing to DMA signaling, timer circuits, etc.). Incoming signals are often coupled to an “interrupt” input signal of the processor, so as to cause the processor to interrupt its present processing task and service the needs of the interrupting interface or circuit. To aid in coordinating processing of multiple such interrupt sources, a storage controller often uses a Programmable Interrupt Controller (PIC) or Advanced PIC (APIC), although some controllers may rely only on features of the processor to provide such coordination. The PIC (or an internal feature of the processor) provides priority information for each possible source of an interrupt request signal sent to the processor. This may be achieved, for example, by receiving interrupts at the PIC, and multiplexing the interrupts to generate an interrupt signal for the processor, based upon a priority scheme at the PIC. Thus, higher priority interrupts may be enabled while a lower priority interrupt is being processed.
Prioritized interrupt processing is generally desirable because it allows a storage controller to process mission-critical interrupts quickly (e.g., interrupts relating to critical errors, data throughput, etc.) while also reducing the impact of low-priority interrupts (e.g., monitoring or debugging interrupts) on system overhead for the storage system. As presently practiced, interrupt priorities are defined for a storage controller at the “hardcoded” firmware level (i.e., fixed data in a hardware device or otherwise compiled into machine-code). Firmware may exist, for example, in microcode or machine code resident in a program memory coupled with the processor. Thus, the order of interrupt scheduling and priority processing for a given storage controller cannot be changed during the run time or life cycle of the firmware for the storage controller, because the entire firmware must be replaced to change an interrupt priority. Replacing or updating the firmware typically requires that the storage controller be taken offline while the firmware is modified, and further requires that the storage controller be re-initialized with the new firmware. This is undesirable, as it may result in a long period of time while the storage controller and associated storage devices are unavailable to a host system.
In addition to problems associated with taking a storage controller offline, the firmware development process used to modify existing firmware is associated with several known pitfalls. For example, installing new firmware at an interrupt controller may result in integration issues with other components of the storage system or with components coupled with the storage system. Thus, even when implementing only minor changes in firmware, development generally requires extensive testing in a pre-production integration laboratory in order to ensure that the new firmware is error-free and compatible with other components and systems. The development and testing problems can be exacerbated when the storage controller is implemented by a manufacturer in a wide variety of different storage system configurations for a variety of customers, because there are a greater number of potential incompatibilities. Unfortunately, different customers may have different processing and data management priorities for a given storage system configuration which will impact the preferred interrupt priorities for that system. A manufacturer therefore may have to test a wide variety of configurations of a system even for a small change to the firmware relating to interrupt priorities.
Thus it is an ongoing challenge to manage the priorities of interrupts in a storage system according to the varying demands of storage system customers.